Developing software programs can be a complex task. In particular, ensuring that a program conforms to desired standards in relation to, for example, formatting, security, performance, and so on can be a significant difficulty especially when a program is relatively robust and/or complex. That is, as the program becomes longer and includes more complex programmatic/data structures, identifying vulnerable aspects of the program (e.g., functions) and how the functions interact with other parts of the program increases in difficulty. In general, developers may reference control flow graphs in attempts to optimize a program and/or to better understand relationships between different functions/segments within the program. However, existing approaches to generating control flow graphs function after the program is complete and the existing approaches also produce large complex graphs that can be impractical for a developer to interpret. Accordingly, the present approaches do not provide the control flow graph in a timely manner nor interpretable so as to be useful when originally generating the program.
Similarly, adding instrumentation into the source code of the program can further complicate development. Instrumentation, in the context of computer programs, generally refers to additional code segment(s) that are included within a program to provide additional functionality. The additional functionality can relate to additional functional hooks, ensuring security, providing for traceability, enforcing control flow, and so on. However, the instrumentation is at times not accurately coded or may be unintentionally left out considering the many varied segments of instrumentation that are generally to be included within the program and subsequently verified. Consequently, functionality of the program that the instrumentation controls such as the program flow may not function appropriately leading to further difficulties such as security holes resulting from vulnerable functions.